[レポート]運用してわかった SIEM on Amazon OpenSearch Service の構築とインシデント対応の実際 – AWS Security Roadshow Japan 2021 #awscloud #AWSSecurityRoadshow

AWS Security Roadshow Japan 2021で行われた「運用してわかった SIEM on Amazon OpenSearch Service の構築とインシデント対応の実際」のセッションレポートです

#AWS Security Roadshow Japan 2021

#AWS

#セキュリティ

#AWS Security Roadshow Japan

臼田佳祐

2021.11.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

本日はAWS Security Roadshow Japan 2021で行われた以下の講演のレポートです。

運用してわかった SIEM on Amazon OpenSearch Service の構築とインシデント対応の実際

freee PSIRT では、SIEM on Amazon OpenSearch Service を用いて、サービスのセキュリティを維持する業務を遂行しています。本セッションでは、1 年前に freee PSIRT が抱えていた課題とその解決方法、SIEM の構築や運用を行う上で注意すべき点、実際の incident 対応の例、残る課題今後の展望をご紹介します。

Freee株式会社 PSIRT Tech Lead　杉浦英史氏

レポート

freeeの紹介
- SaaSで会計サービスを提供
- 会社のバックエンドを支えるサービスも沢山提供している
- スモールビジネスを、世界の主役に
- 社員数が300人以下の会社が対象
  - バックオフィスを自動化して本業に集中してもらう
  - リアルタイムに経営する情報を集めて可視化
- お客様から集めたデータを守ることがPSIRTのしごと
PSIRTの日常
- PSIRTとは
  - CISOの下にCSIRTとPSIRT
  - ここでのCSIRTのCはCorporate
  - PはProduct
- 多層防御をする
  - 攻撃パスは外部、DevSecOps、内部
  - 何が起きたかわかるようにログを集約してアラート、解析のためにSIEMを使っている
  - すべての段階でログを取っておかないと何もわからない
- 日々の運用
  - OODA loop
  - 1週間で回している
  - 随時インシデントハンドリングをして足りなかったものをもくもくする
なぜ必要なのか
- Logは取得できるが
  - ログが多すぎて1つのシステムで調べることが難しい
  - Elasticsearch3つで見ていた
  - 分離されていて大変
  - 問題点
    - アラート沢山
    - 解析できない
SIEMでできること
- SIEM on OpenSearch Service
- いろんなログを集めて相関分析ができる
- デプロイすれば簡単に環境ができあがる
- S3にログを入れさえすればETLして取り込まれる
- 相関分析が可能なダッシュボードが手に入る
- Elastic Common Schemaに整形してくれる
  - AWSサービスによって形式が違うため
- フィルターや調査が簡単にできるようになった
デモ
- GuardDutyで検知したものを確認
  - Mediumのものをチェック
  - EC2インスタンスが普段アクセスしていない場所にアクセスしていた
  - 管理者に操作をしたか確認してクローズ
- アラートから詳細調査
  - ルートで誰か作業している
  - Trailのダッシュボードからルートの作業が20個あることがわかった
  - Describeがほとんど
  - サポートレベルの変更だけが変更系
  - 作業者の証言と一致
- 早く処理できるようになった
- 人的、物的なresource効率が良くなった
  - 商用SIEMと比較して1/5ほどコスト削減できた
工夫したところ
- サポート外のログをサポート
  - pluginを実装する
    - 設定ファイル内でフィールドとのマッピングを行う
    - マッピングだけできない場合にはifを使う
  - WAFv1の対応をしたり、v2の拡張をしたりした
    - pythonのコードを調整
- 多量のログの対応
  - 大きなログは自動で処理が分割される
  - 小さなオブジェクトを多量に受け付ける場合
  - Lambdaを分割して対応
  - さらにラッパーを作ってバルクで入れる処理も実装
  - daily indexで楽に
- アラート設定
  - ポチポチ設定するだけ
  - WAFのログだけポーリングにしたので別経路でアラート
- OpenSearchの扱い
  - 運用の注意点
  - index fullにならないように
  - Daily indexで細かく分ける
  - 積極的にUltrawarmに移す
    - 必要なくなったらCold
    - 移行は一瞬で済む
  - Index State Managementを使う
  - Planningしてフィードバック
  - 25%でストレージアラート出す
  - VPCに閉じ込めることは今はCDK設定でできる
    - VPCEがあることを確認
実際のスレット対応
- WAFとIPSで相関分析
  - 見なくていいものを除外していく
  - XSSしているものに注目
  - 実際のパスに対してXSSしようとしている
  - WAFはいくつか通している
  - すり抜けているものはIPSでブロックしている
  - WAFは全て止められるわけではないので多層防御
  - 今回は後ろで止められていることが確認できた
- S3に直接GetObjectが確認された
  - 実在するパスに来ていた
  - S3名の推測がされていた
- DoS
  - 日に2回はねている
  - Rate Limitで引っかかっている
  - 2つのIPだけだった
  - IPベースで確認
  - 時間ベースで大量のリクエストをお客様がしていた
  - 連絡して気をつけてもらうようにした
  - ログがあるので正確な説明ができた
TODO
- DLQの自動処理
  - 膨大なアクセスがあるとDLQに入れている
  - 手動でロードしている
- 振り返りしているがWeekly
  - dailyで振り返りしたい
  - 怪しいものに来づける能力をみんなで付けていきたい
  - 対応をトラッキング
  - 自動化していきたい
今後の展望
- 攻撃の予兆、糸口に気づく
- 大量のインポートに対処したい
- PCI-DSS、SOC2に準拠した状況の維持